TURBU Tech

The second sneak preview is out now.  It’s quite a bit more interesting than the first one.  FinalBuilder being added to the package will make it a lot easier for me to get builds set up for the TURBU project.  Right now I have to do it all by hand.  So far I haven’t missed a step and ended up releasing it, but if there’s a way to reduce the chance of that happening in the future I’d definitely appreciate it.  I just wonder if it’ll be in all editions or just the higher-level SKUs.

Then they mentioned AQTime, which looked interesting but IMO brings up more questions than it answers.  For example, “Since this is the standard edition, not all of the profilers are enabled.” (9:13)  But I don’t see any of the profilers on that list grayed out.  And again, will this be in all editions, or just the high-level ones?

Also, will it come with an extension to the Open Tools API to allow other profilers to be integrated?  AQTime has some great features, but its core feature, performance profiling, uses instrumenting that slows your app down horribly, which makes it unsuitable for a lot of uses.  I prefer Sampling Profiler, which gives a good picture of what you’re spending your time doing without instrumenting your program.  It doesn’t provide the perfect counting accuracy that instrumenting does, but most of the time you don’t actually need that anyway in order to track down performance problems.  If there was a way to integrate Sampling Profiler into Delphi, it would make a good compliment to AQTime’s other profilers.

As for CodeSite, I don’t have too much to say about that, because I don’t know enough about how it works to discuss it very well.  Logging’s definitely useful, but usually in different ways than what they were demonstrating on the video.  For example, if CodeSite can only output to that popup window, it’s worthless IMO.  But if it can write to a file, or better yet if it allows you to create and register custom outputs of some kind, that would be a big help.

The one thing I’m a bit worried about is price.  Delphi’s got three general problems, which need to be resolved independently.

1. Missing features.  No 64-bit, no cross-platform, no data binding, no LINQ, etc.
2. Bugs and quality issues.  Glitchy generics, *Insight, the helpfiles, etc.
3. Price.  No explanation needed

Delphi 2011’s main point was supposed to be addressing a missing feature.  That ended up not happening, as the team members have been explaining, because they don’t have enough time to get it working at a good quality level.  That’s definitely a praiseworthy attitude, but I’m a bit worried at seeing all these expensive third-party tools being suddenly announced as part of the product.  They don’t actually do anything to solve the three main problems facing Delphi, and I’m a bit worried that they’ll end up taking the price even higher.

They’ve mentioned their commitment to quality several times, and specifically that they’ve done a lot of work to fix the generics issues.  That’s great, and if they’ve allocated some resources to getting a Error Insight and Code Completion working properly that’ll be even better.  But even so, not having the main missing feature we were expecting would be delivered is going to do a lot to reduce the perceived quality of the release, even if the objective quality has gone up quite a bit since D2010.  Quality improvements are generally expected to be part of an update, not a new release.  (The “I paid good money for this with the expectation that the promised features would actually work” argument.)

I really hope I’m interpreting this wrong, but what it looks like to me is that in order to avoid the new version being perceived as “just a bugfix release” that isn’t worth the price, Embarcadero decided to bundle a bunch of expensive tools to make it appear to be more worth the cost.  If that’s what they’re doing, there are two ways to do it, and both will hurt them.  Either the price stays about the same as it was for D2010, but they’re paying a share of it to the owners of AQTime, FinalBuilder, etc, so they lose a lot of revenue, or they pass that cost along to us, the price goes up, (without delivering the anticipated new feature,) and a lot of people end up not wanting to buy it at that price, so they lose a lot of revenue.

What I would prefer, and what I would do if it was my product, is to negotiate some sort of deal with the creators of these other products where people who buy Delphi XE can pick them up at a discount, and then sell the actual Delphi license to us at a reduced price.  That would help improve sales, or at the very least help stem the loss of sales resulting from not having cross-platform available, and no one ends up paying for add-on products they don’t need.  (And not everyone will need them.  Where I work we’ve got a bunch of developers and one build machine.  If we all got a copy of FinalBuilder… what would we do with it?)

I really hope I’m wrong about this, but this is what it looks like Embarcadero is doing.  I just wish they wouldn’t, since I don’t think it will actually be good for Delphi users, or for Delphi itself.